A collaborative framework that breaks down information barriers 打破資訊壁壘的協作框架
約一萬年前，人類從狩獵採集轉向了農耕生活。這種生活方式的轉變，催生了對農作物、人口和秩序管理的新需求，也帶來了一系列創新。這個轉變引發了“農業革命”（Agricultural Revolution），雖然帶來了糧食安全，卻也帶來了分工、等級制度和中心化權力。不像遊牧人群的自由，農民工作更加辛苦，而掌握土地與資源的小部分精英則享受特權。
Agricultural Environment
Agricultural Social Structure 農業社會結構
- 中央權力（Central Power）：掌控土地、資源、知識與決策權。
- 中層流程（Directed Processes）：包括灌溉、磨粉、倉儲、安全等日常管理。
- 勞動力活動（Labour Activity）：如耕作、收割、除草、運輸等體力勞動。
這個模型說明瞭啥？
權力越往中心越集中，越靠外的人越累，決定權卻越少。
創新（比如更高效的種植法）也只能從中心那小撮人發起，外圈人只能執行，無法提出或推動改變。
這種模式雖然組織上“整齊劃一”，但也極其壓抑、死板、不靈活。
雖然這是古代的圖，但很多現代公司也是一樣的結構：
老闆或高層定戰略、做決定
中層傳話、安排執行
一線員工只負責“幹活”，沒有創新空間
結果就是：創新被堵死、資訊不流動、人才受限，公司像個“古代農莊”在運作。
模擬場景
| 流程階段 | 發生了什麼？ | 問題 |
|---|---|---|
| 1. 老闆定方向 | 老闆拍腦袋：“我們要做一個‘使用者社群’，類似小紅書！” | 決策來源於直覺，無調研、無市場驗證，且無使用者視角 |
| 2. 產品立項會 | 產品經理簡單整理老闆發言，轉述為“上線社群模組”需求 | 缺乏深入挖掘動機和使用者價值，變成“任務轉發” |
| 3. UI/UX 介入 | UI被拉去畫頁面，UX沒有參與需求討論，連目標都不清楚 | 無使用者研究，也無體驗路徑，UI成“畫圖工具人” |
| 4. 功能設計&評審 | 老闆一句“我要的是這個感覺”，UI被反覆改顏色、字型 | 決策權集中在老闆，專業建議被忽視，改稿靠猜老闆口味 |
| 5. 前端開發上線 | 設計臨時改，邏輯混亂，開發照搬設計稿，上線糊弄 | 缺乏統一流程與驗收機制，開發成“搬磚工” |
| 6. 使用者使用 | 使用者根本不清楚社群要幹嘛，頁面也沒引導，沒人發帖 | 沒有使用者調研與引導設計，功能“看得懂但沒人用” |
| 7. 老闆質疑 | 老闆說：“你們是不是設計做差了？我都說要參考小紅書！” | 不復盤、不問原因，繼續指責前線，系統性失敗迴圈 |
Design Organizational Structure 設計組織分工結構
| 維度 | UI 設計 | UX 設計 | 產品設計 | CX 設計 | 服務設計 |
|---|---|---|---|---|---|
| 英文全稱 | User Interface Design | User Experience Design | Product Design | Customer Experience Design | Service Design |
| 主要關注物件 | 介面元素（按鈕、顏色、排版） | 使用者操作路徑、使用邏輯 | 產品的定位、功能與商業價值 | 顧客在整個生命週期中的體驗感受 | 整個服務體系的流程、結構與支援系統 |
| 一句話解釋 | 讓東西好看又好用 | 讓使用者操作順暢、舒服 | 讓產品對得起市場和業務目標 | 讓顧客從頭到尾都覺得服務貼心 | 讓前臺與後臺所有流程配合得順暢高效 |
| 典型任務 | 配色、圖示、字型、按鈕樣式、視覺一致性 | 使用者調研、流程圖、線框圖、可用性測試 | 需求優先順序、功能設計、資料目標、產品邏輯 | 顧客旅程圖、客戶反饋分析、售後體驗最佳化 | 服務藍圖、跨部門流程、系統整合、角色協同 |
| 使用的方法 | 視覺設計、設計系統、原子設計 | 使用者旅程圖、使用者測試、IA 資訊架構 | PRD檔案、MVP策略、商業建模 | 客戶旅程地圖（Customer Journey Map）、NPS分析 | 服務藍圖（Service Blueprint）、觸點矩陣、流程設計 |
| 最常打交道的人 | 設計師、前端開發 | UI設計、產品經理、研究員 | UX設計、商業團隊、工程師 | 客服、市場、銷售、運營 | 運維、IT、客服、法務、政策部門 |
| 典型成果物 | 高保真原型、視覺稿、設計系統 | 線框圖、原型、測試報告 | 產品功能清單、MVP方案、增長實驗設計 | 客戶滿意度分析、客戶旅程地圖、投訴流程最佳化 | 服務藍圖、角色矩陣、操作手冊、端到端服務策略 |
| 作用範圍邊界 | 產品的表現層（UI介面） | 產品的操作層（使用者流程） | 產品的結構與功能層（邏輯層） | 顧客從知道品牌到售後整個體驗鏈條 | 服務從前臺到後臺的系統層與組織協作結構 |
| 關注的痛點型別 | 看起來亂、用起來卡 | 操作不清楚、流程不順暢 | 功能多餘、策略錯誤 | 顧客抱怨多、滿意度低 | 各部門脫節、服務碎片化、交付質量差 |
| 決策影響力層級 | 影響“好不好看、用不使用者” | 影響“用得順不順” | 影響“做不做這個功能、值不值這個產品” | 影響“客戶走不走、推不推薦” | 影響“服務做不做得成、交付順不順” |
| 職能 | 舉例說明（以打車產品為例） |
|---|---|
| UI 設計 | 按鈕怎麼放、顏色好不好看、字型是否易讀 |
| UX 設計 | 使用者從開啟App到叫車成功的每一步是否順暢 |
| 產品設計 | 是否加拼車功能？司機評分體系怎麼設計？ |
| CX 設計 | 使用者從註冊、叫車、乘坐、支付、售後的整個體驗是否流暢、滿意 |
| 服務設計 | 客服、司機、乘客、系統、財務、保險等部門之間流程是否協調、系統是否聯動、出現問題時怎麼處理 |
看起來很專業的設計組織，其實也很“封閉”
各自為政：UI 的做 UI，產品只管功能，服務設計沒人理
合作困難：界限太清楚，反而沒人願意“跨線”交流
視角單一：只從自己的角色看問題，容易產生偏見
知識不共享：各部門有自己的檔案、工具、流程，別人進不來
歷史上有很多例子
柯達沒趕上數碼浪潮，是因為只想著賣膠捲
諾基亞被蘋果打垮，是因為他們覺得“換個UI”就夠了
場景模擬
| 流程節點 | 發生了什麼？ | 問題 |
|---|---|---|
| 產品經理提需求 | 「老闆說最近客戶投訴多，做一個投訴入口」 | 需求是“上面要我做”，不是基於使用者反饋 |
| 產品經理寫PRD | 沒有和客服、服務設計溝通，只寫了個「提交投訴表單」的功能 | 只滿足“任務完成”，沒解決問題本質 |
| UI設計上馬 | 做了個好看的“投訴按鈕”和表單頁面 | 不知道表單誰處理，使用者投訴後發生什麼 |
| 開發上線 | 表單上線，使用者能填寫 | 表單直連郵箱，沒有工單系統，沒人跟進 |
| 客戶填寫投訴 | 沒人回覆，體驗更差 | 反而引發負面口碑，內部互相甩鍋 |
| 總結會議 | CX說使用者不滿，服務設計說流程沒人管，產品說功能已做完 | 每個角色都“做了事”，但系統失敗 |
Products & Services 產品與服務為核心結構
和之前“同心圓結構”完全不同，它打破了層級感，讓不同職能（UI、UX、產品、CX、服務設計）都像是平等的節點，圍繞一個共同目標產品與服務（Products & Services）進行互動。
靠連線、流動、反饋維持運轉
中心是“Products & Services”（產品與服務）周圍有5個設計能力點：UI、UX、產品設計、CX、服務設計，每個設計職能都向中心連出“紅線”代表創新流動（lifeblood），外部還有“黃色虛線”代表反饋系統，連著外部力量（如客戶、法規）
| 角色 | 內容 | 代表誰 | 功能是什麼 |
|---|---|---|---|
| 1. 系統環境 | Organisation X | 企業、醫院、學校等整體組織 | 容納所有團隊、產品、使用者的“大容器” |
| 2. 內/外邊界 | UI/UX/CX/Product/Service + 客戶與法規 | 內部設計職能 + 外部環境變數 | 各自貢獻能力或提出外部挑戰 |
| 3. 產品服務介面 | Products & Services | 產品、流程、系統、平臺等 | 連線內部能力與外部需求的橋樑 |
| 4. 創新血液 | 紅線（Innovation Lifeblood） | 設計能力貢獻通道 | 各職能透過協作把能力注入產品系統 |
| 5. 反饋神經 | 黃線（Systemic Feedback） | 使用者、市場、法規等的回傳訊號 | 組織靠它學習、適應、更新方向 |
舉個例子做個對比：網際網路公司要上線一個「打車App的乘客投訴功能」
場景模擬
| 流程階段 | 發生了什麼？ | 問題 |
|---|---|---|
| 高層提出需求 | 市場負責人在覆盤會上說：“現在使用者留存不行，做個積分商城，用活躍換福利” | 起點是資料+競品刺激，沒有深入理解使用者動機，也未制定評估機制 |
| 產品快速成案 | 產品經理整理了功能清單：“使用者積分累積→兌換商品→發貨”三步閉環，提交PRD | PRD只覆蓋“兌換邏輯”，缺乏前置入口設計、積分來源清晰性、使用者引導流程 |
| UI設計提審 | UI設計做了首頁按鈕和商城商品卡片，視覺風格一致，元件通用 | UI上點選即可兌換，但未設計“積分不足”“積分獲取方式”的狀態反饋，互動缺少預期管理 |
| UX未系統參與 | UX僅參與一次評審，未跟進旅程細節；無資訊結構圖，無旅程地圖 | 使用者從哪裡開始兌換、為何要兌換、兌換是否有成就感都未梳理 |
| 服務設計缺失 | 商城兌換後發貨由運營人工處理，流程不透明，客服無跟進機制 | 使用者兌換後未收到簡訊，無進度展示，造成“兌換即消失”的負體驗 |
| CX沒有提前介入 | 客服沒有收到培訓內容，也無話術模板；使用者問“怎麼賺積分”時常答不上來 | 內部沒有形成一套“使用者教育+引導+答疑”的話術系統，容易誤解積分規則 |
| 產品準時上線 | 功能如期上線，有人使用，日兌換量達預期 | 但使用者對“積分怎麼來”“為什麼兌換完沒提示”“客服不懂”等問題集中爆發 |
| 資料略低於預期 | 使用人數不高，兌換率較低，復購使用者主要是“高頻使用者”，未觸達“沉默群體” | 功能策略上沒帶來新使用者活躍提升，只服務了已有高活躍使用者 |
| 覆盤會上討論 | 團隊認為功能沒問題，是“使用者沒發現”，建議下輪加強引導 | 將結果歸因為“宣傳不夠”，忽視了產品邏輯、引導和閉環設計的系統性薄弱 |
Decentralized shared core resource structure 去中心化共享核心資源結構
- 中心是一個大圓：Commons（共享核心）包括標準、工具、價值觀、資源等
- 周圍是各類職能能力：UI、UX、Product、Service、CX
- 每個職能透過紅線（Innovation Lifeblood）和黃線（Systemic Feedback）與“共享核心”連通
Commons 中包含哪些“共享資產”
| 分類 | 中文解釋 |
|---|---|
| Design & Accessibility Standards | 設計系統、無障礙標準 |
| Research & Insight Repositories | 使用者調研庫、競品研究、客戶訪談記錄 |
| Prototyping & Testing Tools | 原型工具庫、測試方法、模版 |
| Strategic Planning & Frameworks | 路線圖、規劃結構、專案計劃模版 |
| Cultural Rituals & Shared Values | 團隊共識、價值觀手冊、團隊儀式 |
| Legal & Governance Templates | 合規模版、隱私策略、風險告知檔案 |
“統一沉澱 → 廣泛呼叫 → 及時反饋 → 持續進化”。
1.核心（Commons 公域）的建立
在公司或團隊內部，設立一個共享的“知識與規範庫”。比如：設計系統（Design System）、研究檔案庫、策略模板庫、程式碼規範、常見測試工具等。所有專案團隊不需要從零開始，而是可以從這個“共享庫”裡拿到可複用的標準和經驗。
大廠的 Design System（Ant Design、Material Design） 就是典型的 Commons：UI、互動、無障礙規範都集中在一套系統裡。
2.戰略性（Strategic）價值
將業務目標、路線圖、研究洞察放進 Commons。不同團隊在做各自專案時，可以對齊長期目標，而不是區域性最優。
產品團隊和增長團隊都從一個共享的“使用者研究庫”裡獲取使用者痛點，避免策略衝突。投資人彙報的“戰略規劃”檔案也能沉澱到這裡，供其他部門決策時參考。
3.文化性（Cultural）價值
透過共享價值觀和邊界來減少內耗。比如寫明“所有實驗都必須考慮使用者隱私”，或者“所有 UI 必須支援無障礙模式”。形成“潛規則”，讓不同團隊做事更順暢，不用每次開會拉扯。
Google 內部的 OKR 制度 就是一種文化 commons：大家圍繞共享目標做決策。
4.反饋性（Feedback）機制
透過資料與覆盤把結果迴流到核心。比如：上線新功能後，使用者體驗調研、AB 測試資料都要沉澱到 Commons。避免同樣的錯誤在不同團隊重複發生，也能讓好的經驗快速擴散。
Airbnb 的 Experiment Platform：每個實驗結果都會被歸檔到系統裡，任何團隊都能查閱。
| 流程階段 | 發生了什麼？ | 優勢體現 |
|---|---|---|
| 使用者反饋共識形成 | CX 團隊監測 VOC 資料，發現“投訴流程割裂”是核心痛點，召集產品、服務設計開會共建 | 不是某人拍腦袋，是基於資料形成共識 |
| 多方協同建模 | 產品、UX、服務設計聯合使用“服務藍圖模板”畫出投訴路徑，識別觸點、接收人、通知機制 | 共建藍圖解決“誰處理、如何處理” |
| UI/UX設計 | UI基於共享元件庫設計帶狀態反饋的投訴入口（如：提交成功→處理中→處理完畢） | 資訊透明，使用者知道下一步發生什麼 |
| 服務設計介入 | 服務設計制定投訴響應時限、客服告知機制、升級規則 | 體驗設計不止停留在介面，而是流程 |
| 上線後追蹤 | 系統自動打標籤、生成體驗資料，Commons庫沉澱了完整投訴機制設計檔案 | 可複用、可追溯、可最佳化 |
| 持續最佳化 | 投訴資料被實時分析，2周後最佳化了入口文案和流程時間 | 建立持續反饋機制，實現產品自愈能力 |